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METHODS OF PROVIDING MEDICAL INFORMATION AND 
RELATED SYSTEMS AND COMPUTER PROGRAM PRODUCTS 

RELATED APPLICATIONS 

The present application claims priority from U.S. Provisional Application No. 
60/322,865 filed September 17, 200 1, entitled "A Web-Based Operating Room 
Status-Monitor And Anesthesia". The disclosure of U.S. Provisional Application No. 
60/322,865 is hereby incorporated herein in its entirety by reference. 

FIELD OF THE INVENTION 

The present invention relates to methods, systems, and computer program 
products for information processing. 

BACKGROUND 

Only about five percent of hospitals in the US routinely use an anesthesia 
information system for recording an anesthetic record, despite that fact that the 
practice of anesthesia, with its highly structured data, lends itself well to these 
systems. One reason for this is financial, as yet there appear to be few clear 
indications of a significant return on investment for these systems, which tend to be 
expensive. There may also be controversy surrounding the clinical benefits of these 
systems, with some anesthesia staff reluctant to invest in systems because of 
entrenched attitudes to a "spy-in-the-cab", because they would like control over the 
recording of automated data for a case, and/or because they fear the recording of "the 
ugly truth". The main vendors have made little progress in penetrating this market 
over the past 10 years for these and/or other reasons. 

Anesthesia Information Systems (AIS) have evolved significantly since the 1st 
generation Duke Automated Monitoring Equipment (DAME) system in 1972. Initially 
they were simple recording devices using the hardware available at the time, which 
tended to be large and/or unreliable. User input to the DAME was by keyboard and 
bar codes. A diagram of a first generation DAME system is illustrated in Figure 1 . 
As shown, the DAME system included one or more monitoring carts 101, a data 
manager 103, and a printer 105 coupled through a DMXNET Network 107. Each 
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monitoring cart 101 could include a DEC LSI-1 1/02 microcomputer and a barcode 
reader. The data manager could include a DEC PDP-1 1/23 minicomputer, a 5Mb 
hard drive, 256K RAM, and a custom built operating system. 

The second generation of AIS was based on PC technology, with more reliable 
operating systems, software and hardware. The Arkive AIS was an example of this, 
and the largest installation of this type anywhere in the world was believed to be at 
Duke University Medical Center in Durham, North Carolina. A diagram of the 
Arkive system is illustrated in Figure 2. User input was by touch screen plasma 
display. These were file serving, networked systems with rudimentary Paradox or 
Access databases usually running on a Novell platform. As shown in Figure 2, an 
Arkive system could include a plurality of workstations 201, a Novel network file 
server 203, a plurality of network printers 205, a mirrored database 207, and data 
storage 209, coupled by network 211. 

The third generation of AIS is that of the current installed base. Two tier or three 
tier client/server systems now use robust relational databases such as Microsoft SQL 
Server, Sybase Adaptive Server, or the like. The client applications are usually 'fat 1 in 
that a great deal of processing is done on the client, usually because of the 
requirement to handle monitored data streams from equipment attached to the patient. 
Systems from Draeger Medical Inc., Philips Medical Systems Inc., GE, Surgical 
Information Systems Inc., and PICIS Inc. generally have this architecture at their 
heart. The Draeger system, referred to as the Saturn Information System or "Saturn", 
is illustrated in Figure 3. As shown in Figure 3, the Saturn Information System can 
include a plurality of clinical workstations 311, a plurality of non-clinical 
workstations 313, and a database server 315 coupled by AIS network 317. 

The current generation of AIS generally uses heavyweight client software ("fat 
client") on dedicated workstations. The progression to 'thin client' solutions may be 
slow due to the desire to perform significant data processing of monitored data 
streams at the client devices (i.e. clinical workstations), and the desire for redundancy 
of information on the client in the event of a network failure. The usual architectural 
solutions to this are local database structures, which replicate to the main server. The 
vendors appear to have spent most of their effort making these complex software 
systems work reliably in a demanding clinical environment, and they appear to have 
mostly succeeded. 



2 



WO 03/025703 



PCT/US02/29354 



SUMMARY 

According to embodiments of the present invention, methods of displaying 
operating room scheduling information can include retrieving scheduling information 
for scheduled operations in a plurality of operating rooms of a hospital area over a 
predetermined time period. The scheduling information for the scheduled operations 
can include a patient identification and a procedure identification. Current status 
information is retrieved for at least one of the scheduled operations while in progress 
wherein the current status information is selected from one of a plurality of milestones 
of a surgical operation. A table of scheduled operations over the predetermined time 
period is provided for display at a client device wherein for a scheduled operation, the 
table includes the respective patient identification and procedure identification 
wherein the table further includes the current status information. 

According to additional embodiments of the present invention, methods of 
retrieving medical information can include retrieving scheduling information for 
scheduled operations meeting a predefined criteria wherein the scheduling 
information for the scheduled operations includes a patient identification and a 
procedure identification. A table of all scheduled operations can be provided for 
display at a client device wherein for each scheduled operation, the table includes the 
respective patient identification and procedure identification. Selection of one of the 
patient identifications from the table of scheduled operations meeting the predefined 
criteria can be accepted, and responsive to accepting selection of the patient 
identification, at least one case identification corresponding to the patient 
identification can be retrieved for display at a client device. 

According to yet additional embodiments of the present invention, methods of 
displaying anesthesia records can include operations performed by data processing 
systems. In particular, a data processing system can accept entry of information 
identifying a surgical operation wherein the information is entered via a client device 
in communication with the data processing system. Anesthesia data corresponding to 
the identified surgical operation can be retrieved, and an anesthesia record can be built 
using the retrieved anesthesia data. Secure communication of the anesthesia record 
can be provided to the client device for display of the anesthesia record at the client 
device. 

BRIEF DESCRIPTION OF THE DRAWINGS 
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Figure 1 is a diagram illustrating a DAME Anesthesia Information System 
according to the prior art. 

Figure 2 is a diagram illustrating an ARKIVE Anesthesia Information System 
according to the prior art. 

Figure 3 is a diagram illustrating a Saturn Information System according to the 

prior art. 

Figure 4 is a diagram illustrating information systems, methods, and computer 
program products according to embodiments of the present invention. 

Figure 5 illustrates use of a test server certificate according to embodiments of 
the present invention. 

Figure 6 illustrates a Choices page according to embodiments of the present 
invention. 

Figure 7 illustrates the Tomcat application server (open source software from 
the Jakarta Project, http://jakarta.apache.org) running in a Java Virtual Machine on a 
server according to embodiments of the present invention. 

Figure 8 illustrates Tomcat and an Imageserver running in a Java Virtual 
Machine on a server according to embodiments of the present invention. 

Figures 9 and 10 illustrate packages associated with ORview according to 
embodiments of the present invention. 

Figure 1 1 illustrates an organization of database connectivity according to 
embodiments of the present invention. 

Figure 12 illustrates image processing techniques according to embodiments 
of the present invention. 

Figure 13 illustrates pages of information and interrelations therebetween 
according to embodiments of the present invention. 

Figure 14 illustrates a Choices page according to embodiments of the present 
invention. 

Figure 15 illustrates a Search page according to embodiments of the present 
invention. 

Figure 16 illustrates a Search Results page according to embodiments of the 
present invention. 

Figure 17 illustrates an Operating Room Status Page according to 
embodiments of the present invention. 
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Figure 1 8 illustrates display of "break relief information according to 
embodiments of the present invention. 

Figure 19 illustrates operations of generating a user schedule according to 
embodiments of the present invention. 

Figure 20 illustrates an Anesthesia Record Page according to embodiments of 
the present invention. 

Figures 21 and 22 illustrate event bars according to embodiments of the 
present invention. 

Figure 23 illustrates graphical vital signs according to embodiments of the 
present invention. 

Figure 24 illustrates operations of generating an anesthesia record page 
according to embodiments of the present invention. 

Figure 25 illustrates security features according to embodiments of the present 
invention. 

Figure 26 illustrates an authentication schema according to embodiments of 
the present invention. 

Figure 27 illustrates a password challenge according to embodiments of the 
present invention. 

Figure 28 illustrates a Change Password Page according to embodiments of 
the present invention. 

Figure 29 illustrates an audit scheme according to embodiments of the present 
invention. 

Figure 30 illustrates organizations of registrations and passwords according to 
embodiments of the present invention. 

Figures 31-34 are flow charts illustrating methods, systems, and computer 
program products according to embodiments of the present invention. 

Figure 35 is a block diagram illustrating information processing environments 
according to embodiments of the present invention. 

DETAILED DESCRIPTION 

The present invention now is described more fully hereinafter with reference 
to the accompanying drawings, in which preferred embodiments of the invention are 
shown. This invention may, however, be embodied in many different forms and 
should not be construed as limited to the embodiments set forth herein; rather, these 
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embodiments are provided so that this disclosure will be thorough and complete, and 
will fully convey the scope of the invention to those skilled in the art. 

Embodiments of the invention can include a set of web-applications which can 
extend the functionality of anesthesia information systems by adding, in some 
embodiments, a web "wrapper" around the data collected by these systems. 
Embodiments of the invention can dramatically increase the availability and derived 
functionality of the patient information. Embodiments of the invention can provide 
additions in functionality including a web-based operating room status monitor, a 
web-based search mechanism for previous anesthesia records and/or a dynamic, 
graphical web-based representation of real-time and past anesthesia records. 
Embodiments of the invention can make these functions available on the Internet with 
a robustness sufficient for production use in a major hospital. Moreover, embodiments 
of the invention can act as a hosting service and make records and schedules available 
for multiple hospitals using various anesthesia information systems. This capability 
may be limited only by the power of the hardware and the available Internet 
connection speed. 

Using embodiments of the invention, staff can look up anesthesia and 
postoperative care records from any Internet client in a secure fashion. They can also 
view the status of running or scheduled cases in their operating room suite from any 
Internet client, and drill down if desired, for example using HTML links, to view the 
case in a particular operating room. Security of patient and staff information can be 
maintained. 

The increase in functionality offered by embodiments of the invention may open 
the market for Anesthesia Information systems. Its advantages of the widespread 
dissemination of case and schedule information to the anesthesia, nursing, and/or 
administrative staff inside and/or outside their normal workplace (i.e. at home, in 
doctor's offices, in break areas, in administrator's offices, etc.), may alone justify the 
cost of perioperative information systems on the basis of an increase in clinical case 
awareness for the patient, workplace convenience for clinical staff and a powerful 
efficiency tool for administrators. 

Embodiments of the invention can use a middle tier web application server 
functionally set between the Anesthesia Information System database and the Internet. 
Requests for information from Internet clients are met by the application server layer, 
which queries the database, processes the data, draws the graphics and returns HTML 
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pages with embedded images to the original Internet client. Figure 4 illustrates 
embodiments of the invention in block diagram format. 

As shown in Figure 4, information processing systems according to embodiments 
of the present invention can include an application server 411 coupled between a 
database server 413 of an anesthesia information system and the internet 415 or other 
wide area network. As discussed above, an anesthesia information system can include 
a plurality of workstations 421 coupled with a database server 413 over a local area 
network 425 within a hospital. The application server 411 can retrieve desired data 
from the database server 413, use the retrieved data to build records and tables for 
secure distribution over the internet 415 to authorized internet client devices 417. 

Embodiments of the invention can be used by anyone who needs access to 
perioperative data. These uses can include: 

1 . Any clinical staff wanting to look up anesthesia records related to a patient. 
This could be from anywhere with access to an Internet browser. For example 
embodiments of the invention can be incorporated as a link in a web-based 
Medical Information System thus providing a viewable anesthesia record 
anywhere in the hospital. Until now, unwieldy solutions for storing the 
Anesthesia record in the Common Data Repository (CDR) have been 
contemplated, such as creating an Adobe PDF image of the record, and storing 
that. Embodiments of the invention can provide an elegant solution that can 
make the use of scanned images of paper anesthesia records obsolete. There is 
no need to duplicate the data, because existing data can be viewed in a novel 
and robust format. 

2. Remote users who wish to access anesthesia records. For example, to give an 
expert opinion on a live running case in the operating room, or to provide an 
anesthetic record to an outside hospital when they request information about a 
patient's anesthetic history. Perhaps the most common use may be anesthesia 
providers looking up old records from their offices or homes planning their 
approach to the next day's cases (there is a considerable patient safety element 
in this). 

3. Local users of information systems in the operating rooms can use 
embodiments of the invention to provide a more comprehensive and readable 
view of a case than their "fat client" record provided by current Anesthesia 
Information Systems, which may be optimized for data input. 
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4. Users who need to remotely access scheduling information. For example, 
"What cases am I doing tomorrow?" 

5. Administrators managing Operating Room suites and/or recovery areas and/or 
patient waiting areas and/or bed control functions can use live status monitors 
of embodiments of the invention. 

6. Using embodiments of the invention as a status monitor for viewing in coffee 
rooms or "Big Board" central planning areas. Using multi-head video cards, 
embodiments of the invention can be spread over multiple flat panel displays 
to provide a status of all the rooms in a suite. 

7. For Quality Assurance and Audit. Simple database queries can extract cases 
with poor outcomes or cases that have been otherwise flagged for further 
analysis. A link to a reference for an anesthetic record can be emailed 
securely to the hospital's QA committee and risk analysis department. 

8. Embodiments of the present invention can also be used to provide hospital 
inventory control and billing information. For example, Anesthesia Records 
can be provided to the hospital pharmacy so that drugs used during an 
operation can be inventoried and billed more accurately. 

9. Using embodiments of the present invention, care providers and/or 
administrators can look up personalized information about their clinical 
practice using a feature in ORview termed "MyQI". This area can enable 
users to generate dynamic and active views of data regarding their clinical 
practice in comparison to that of their peers. This functionality can thus be 
used to influence clinical practice. Personalized information relating to the 
practice of a particular physician can be provided. A table of all cases for 
which a user is listed an having worked on can be generated. Such a table, for 
example, can include information for each case such as the case information 
provided in Figure 16. Statistical data can also be provided for a particular 
physician. For example, a graphical representation can be provided 
illustrating a number of cases handled by day, week, or month over a 
designated time period. Comparisons can also be provided between a 
particular physician and peer physicians. For example, average drug use(s), 
average cost(s), average or reported event(s), etc. for a physician over a period 
of time can be compared to a comparable average(s) of peer physicians over 
the same period of time. 
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A detailed description of system architectures according to embodiments of the 
invention now will be provided. These detailed embodiments will collectively be 
referred to as ORview. 

The ORview welcome page, "orview.jsp", directs users to the various components 
of ORview. The welcome page resides on a web application server within its Secure 
Sockets Layer (SSL), so a request for the welcome page is met with an offer of a 
digital server certificate which must be accepted to continue. The certificate offers the 
application server's public key of a paired RSA_5 128 bit encryption key pair. This is 
'strong' encryption and provides that from this point the user session will continue 
over an encrypted link between web-client and web-server. 

The ORview development software uses a test server certificate from Verisign 
Inc., so the screen 511 illustrated in Figure 5 can be served suggesting that the key 
being offered is from an untrusted site and asking if the user would like to accept it. 
This is normal SSL protocol. Purchasing a production server certificate may allow 
automatic SSL without this step. 

The welcome page for the application, orview.jsp, can act as a redirector, pointing 
new users to the registration forms, and transparently pointing established users to the 
application itself. ORview.jsp and other JSPs in ORview can use JavaServer Pages 
(JSP) technology from Sun Microsystems, Inc. The first clinical page or Choices 
Page 611 of ORview is "choices.jsp 11 which can be provided as illustrated in Figure 6. 
A link to orview.jsp from any web page can initiate the ORview application. 

ORview can use Tomcat V3.2 as a servlet and JSP container, otherwise known as 
an "application server". Tomcat is freely downloadable from the Internet and is part 
of the Jakarta open source project. Tomcat is a pure Java application and can run in a 
Java Virtual Machine (VM) on a Windows 4.0 NT server 711 as illustrated in Figure 
7. 

Tomcat 3.2 is Sun's endorsed implementation of the Java servlet specification 
v2.3 and JavaServer Pages (JSP) specification vl.2. For Orview, Tomcat has been 
configured with its server.xml file to run as a service in Windows NT and to accept 
SSL connections on port 443, the default port for SSL. Tomcat's insecure default port 
8080 has been disabled, plugging insecure access to the middle tier. Tomcat's internal 
security model uses the Java key store ".keys", and it is here that the server certificate 
key pair resides. Configuration of Tomcat, or any other commercial application server 
in this way may be desirable for ORview. However, ORview is not confined to using 
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Tomcat. Several of the commercial application servers could act as more powerful 
servlet containers, e.g. Bea's WebLogic server or IBM's WebSphere, but these 
application servers may be relatively expensive programs costing $5,000 or more. 
Tomcat should work well enough unless volume gets very high, in which case the 
investment to a commercial application server may be worthwhile. 

ORview can use ImageServer Pro software from Corda Technologies Inc. to 
render and serve highly interactive graphics in its output, the anesthesia record. 
Functionally, all the text-based portions of the delivered HTML page are processed by 
the servlets in Tomcat, while the graphics are processed by ImageServer running on 
Windows NT server 811 as shown in Figure 8. 

ImageServer is a pure Java application designed for high volume financial sites 
with requests for 30,000 to 50,000 images/hour, and is more than capable for the task. 
Also included are the PopChart Image Server Embedder (PCISE) Java classes from 
Corda Technologies Inc. which allow direct communication of ORview with the 
ImageServer, and Popchart.class Java class, which is an HTTP Redirection Adapter 
allowing images to be served back to the requesting page through Tomcat's Secure 
Sockets Layer (SSL). 

The ORview web application, orview.war, includes the code and associated 
files to run ORview. At its core are three Java servlets and a collection of JSPs. The 
servlet classes are contained in a package called orview. ORview includes an XML 
configuration file called web.xml. The web application contains the following 
associated files as shown in the screen images 911 and 1011 of Figures 9 and 10. 
Packages associated with ORview in the "classes" directory include: 

1. com.sybase.jdbc.*; 

2. com.corda.servlet. * ; 

3. javax.*; and 

4. orview.*. 

Of these, com.sybase.jdbc.*, com.corda.servlet.*, and javax.* are freely distributed 
Java packages and classes from Sun Inc., Sybase Inc. and Corda Inc. associated with 
their Java2, JConnect and ImageServer products respectively. Also included in 
ORview. war are some associated image files and the collection of JSPs which control 
user registration and other forms of simple user input. 
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ORview.war is packaged according to the WC3 specification for a web- 
application and contains files to run ORview on the application server environment 
detailed in the previous section. 

ORview uses two configuration files, server.xml and web.xml. server.xml is 
the WC3 compliant XML server configuration file for the Tomcat application server. 
It specifies how Tomcat is to be configured to manage its ports, security, logs and 
realms as well as other core functions specific to the application server. Web.xml is 
the XML configuration file for ORview, and is compliant with the WC3 web- 
application specification. Web.xml serves the following functions: 

1. Identifies servlets to Tomcat and sets initialization and shtml address 
mapping parameters; 

2. Provides the security and Realm settings for the ORview application; and 

3. Provides initialization parameters to the servlets. 

As shown in Figure 1 1, an Orview Windows NT application server 1101 can 
use any Java DataBase Connectivity (JDBC) 2.0 compliant driver 1111 to connect to 
a Relational Database Management System (RDBMS) 1113 of an anesthesia 
information system. For the Saturn Anesthesia Information system, ORview is 
configured using web.xml to use the Sybase JConnect driver v 5.5 which has the 
feature of scrollable result set cursors, part of the JDBC 2.0 standard. The Sybase 
driver is freely distributable and is included in the ORview web application in the 
com.sybase.* package. As discussed above, the application server can be configured 
to provide a Java virtual machine 1117 within which Tomcat 1119 operates. 

The organization of database connectivity in ORview is illustrated in Figure 
1 1 . The core Servlets in ORview use SQL query strings 1115 and a pooled 
connection object to access the database. ORview also uses one stored procedure and 
3 functions on the database, which is done at installation using an initial SQL 
database call. The 4 resident SQL stored procedures and functions are: 

1 . TodaysCasesByUser (Stored Procedure); 

2. GetPatientLocation (function); 

3. GetGroupName(function); and 

4. GetBreakReliefString(function). 

ORview uses sophisticated image processing techniques to efficiently generate 
Shockwave FLASH (Macromedia Inc.) images 1209 in the web screens of the 
anesthesia record 1211 as illustrated in Figure 12. Image generation is managed by a 
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Java software package called ImageServer Pro 1213 from Corda Technologies Inc. 
The principle of its use is to pass a datastream and a graphic template to an image 
rendering engine. The image server renders the graphic as a Macromedia Shockwave 
FLASH vector image and holds it and a reference to it in cached memory 1207 until 
required. The reference to the cached image on the server is embedded in HyperText 
Markup Language (HTML) in the served page to the user, and when the Internet 
Browser parses the embedded image tag, it requests the referenced image from the 
image server which it then displays. After a fixed period, the image server flushes the 
cached images from memory. 

ImageServer Pro is an extremely fast image processing system, capable of 
rendering and serving images for high volume websites such as the financial Internet 
portals. The core ImageServer is a Java application which accepts I/O requests on port 
81 . ORview uses two other features of ImageServer to enable the rapid production of 
secure images. These other features of ImageServer are : 

L The PCISEmbedder 1215 which is a set of Java classes imported into the 
core ORview servlets. Their function is to pass the data stream to the 
ImageServer 1213, set the image generation parameters, incorporate a 
graphic template binary file (Chart.bin) and generate the HTML for the 
embedded graphic with its reference to the cached image on the image 
server. 

2. The HyperText Transfer Protocol (HTTP) Redirection Adapter is Java 
class (PopChart.class) which enables images to be redirected from 
ImageServer 5 s Port 81 to the Secure Sockets Layer (SSL) 1217 on port 
443. Unless this is done, a functional distinction exists between the 
security of text and images served by ORview. The redirection adapter 
ensures that both these data types are encrypted over the web, and that the 
management of this is done by Tomcat's SSL. 
ImageServer Pro need not be on the same physical server, but should be 
accessible via a URL over the Internet. ImageServer Pro has extensive load-balancing 
capability and can be scaled up to meet virtually any demand for image generation. 
ImageServer Pro runs as a service within a Java Virtual Machine 1219 on a Windows 
NT machine 1221. The PCISEmbedder 1215 and PopChart.class 1223 are contained 
in the package com.corda.*, and are imported into the ORview application. 
ImageServer Pro is licensed from Corda per server. Conceivably, a single 
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ImageServer/ ORview application server combination could manage the web page 
generation and graphics processing of multiple hospitals. 

The functionality of ORview may be described with reference to the 
illustration of Figure 13. A log-in may be required for security purposes using a login 
screen 1301. The Choices Page 1311 acts as a portal to the ORview application. 
Using radio button choices or typing a user name, users are able to request the 
anesthesia schedule page 1315 by service, by location, a personalized schedule, or 
initialize a search for anesthesia records pages 1317 for a particular patient using a 
search page 1319. Either a search page 1319 or an anesthesia schedule page 1315 can 
be used to generate a list of anesthesia records 1321 for a particular patient, and the 
list of anesthesia records 1321 can be used to generate a desired anesthesia record 
1317. The flow of a user-session may include the following features: 

1 . Links. For example, selecting "Cardiac" at the Choices screen and then 
hitting the "go" button requests the cardiac schedule for the current day 
and the next day, and a web page is served which shows the cardiac 
schedule in an active tabular format. The schedule pages contain 
embedded links, so hitting the link on a particular patient will initiate a 
search for all anesthetic records associated with that patient, which may 
include a current running record. A page is then served which shows the 
list of anesthetic records for a particular patient, again in a active tabular 
format. Following the links on this page enables the user to drill down to 
individual anesthetic records. The anesthetic record is displayed as a 
combination of tabular and interactive graphical elements. 

2. Navigation throughout the application is by following the links embedded 
in the pages, or by using the Browser's Back and Forward buttons. Most 
of the navigation is managed by HTML 6 get 9 actions using simple 
parameterized queries. This enables individual pages, for example a 
patient's anesthetic record, to be bookmarked without compromising 
patient confidentiality. 

3. Autorefresh. ORview has the facility to enable autorefresh of served pages, 
so the Operating Room schedule pages and Anesthetic records will 
autorefresh at a user specified time interval to give the impression of a 
near real-time live view of these elements. 
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4. Session Management. ORview uses a Java session manager class to handle 
user sessions. BASIC authentication of the user with Username and 
Password is required before any clinical pages are viewable. The session 
manager ensures that this authentication is good for the duration of a single 
user session on their browser, or times out after 120 minutes, whichever is 
sooner. 

As illustrated in Figure 14, the Choices Page 1311 for ORview enables the 
user to select distinct derivatives of information. For example, the following 
derivatives of information may be selected: 

1 . The anesthesia schedule by Division, Location or by "In Progress" cases 
using radio buttons. These are customizable selections by institution 
according to desired functionality. The "In Progress" option selects all 
currently running cases. The default date range is for cases from the 
current date until the next working day, including the spanning of 
weekends, so it is always possible to see the following working day's 
schedule using the system. 

2. Underneath this is an edit box for selection of the schedule by provider. 
This initiates a search for all scheduled cases in the default date range 
where the inputted provider has been involved in the clinical staffing. It 
will show users the cases they have been involved with today, and their 
schedules for tomorrow or Monday, if that is the next working day. 
ORview does not yet anticipate Holidays. 

3. The "Search Old Saturn Records" link initiates the search for all anesthetic 
records related to a patient. 

As illustrated in Figure 15, the Search page 1319 can be used to find all 
anesthetic records associated with a particular Patient. The search is initiated by a user 
entering the Patient's medical record number (MRN), or unique patient identifier, 
which could be a Social Security Number (SSN), for example. The page than passes 
the MRN as a parameter to the servlet CasesByHxno, which performs a series of 
JDBC SQL queries on the database and returns an HTML page with the Anesthesia 
Record Results by patient on it. Other search modalities can be provided, such as 
searching by patient name, the use of wildcard characters and the use of search logic 
to search based on combinations of different types of identifying information and/or 
parts thereof. 
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As illustrated in Figure 16, the Anesthesia Record Search Results page 1321 
can display the output of the servlet CasesByHxno (patient names have been 
removed for confidentiality purposes). The Anesthesia Record Search Results Page 
has been designed to be a primary method of navigating to a patient's individual 
anesthetic records and may be a necessary selection step because a patient may have 
multiple anesthetic encounters recorded in the system. As such, the page should 
display just enough information for the user to identify a particular anesthesia record 
that they may wish to drill down further to view. The input parameter string to the 
servlet can be obtained either from the search page or by following a link from the OR 
Schedule Page. The input parameter, for example, may have a format such as: 

Https://152.3.70.74/orview/casesbylaxno?HXNO=CM0319. 
Moreover, the input parameter can be bookmarked to provide rapid access in the 
future. Features on the Anesthesia Record Search Results page can include: 

1 . An active tabular format. Each row represents an individual anesthetic 
record, and displays a link in the Case ID column to an individual 
anesthetic record. By selecting a particular case identification (CaselD), 
the particular Anesthesia Record can be obtained. 

2. The other columns display patient demographic information relating to the 
previous anesthetic encounters, including the surgical procedure and the 
Attending Anesthesiologist assigned to a case. 

3. The Anesthesia Record Search Results Page can also include alerts such as 
alerts noted during a preoperative screening or note by a health care 
provider from a previous surgical event. For example, an alert icon 
provided on the Search Results page can provide a link to more 
information regarding the alert. 

As shown in Figure 17, the Operating Room Status Page 1315 or monitor is a 
display of the output of the servlet CasesByUser and can be called by accessing the 
selection choices of the Choices Page 1311. The format of this page is active and 
tabular, with each row representing an individual anesthetic case, with links to the 
anesthetic records of an individual patient. The set of cases displayed on this page 
corresponds to the selection criteria from the Choices page, and may represent all the 
cases for a particular hospital, the cases for one service, or just those of an individual 
user, for example. 
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This page can accomplish at least two goals. The Operating Room Status page 
1315 can act as a static schedule for planning purposes, and as a status monitor for a 
group of operating rooms or staff It can act as a status monitor because the data in the 
columns in the page can reflect real-time events entered by users into the anesthesia 
information system database, and this data can autorefresh on the WebPage at 
intervals to give the appearance of real time case status. The inclusion of active links, 
blinking elements and autorefreshed data can give this Page the impression and utility 
of an "Airport Monitor" for the operating rooms, displaying the status of a large 
number of real time events in an effective manner. Features of the Operating Room 
Status Page 1315 can include: 

1 . Cases can be sorted by Date, Operating Room and/or Scheduled Case Start 
time to give the page a standard format of schedules used in many 
operating room suites. 

2. The Case Status column can display the current status of a case depending 
on the status flag in the database; Preop, In Progress, Complete, Cancelled 
or Archived. If the case Status is "In Progress", the column element in that 
row can Blink to highlight that the case is currently active. In this way the 
user gets an immediate view of the active cases in the Operating Room 
(OR) suite. 

3. The OR Name column displays information about the patient's scheduled 
and current location based on machine replication settings in the database. 
The database flags data recorded on particular workstations for a case, so it 
is possible to track exactly where a patient is at a particular time. The 
string shown in this column cab be of the following format: 

Location A=>Location B. 
This format signifies Scheduled Location => Current Location. As such 
this tool enables the user to track the current location of a patient, and the 
difference from the scheduled location. This can be a tremendously 
powerful feature for administrators. For example, the post-anesthesia care 
unit TACIT choice in the welcome page may select all cases which are 
currently active on PACU workstations so that the OR Name column 
displays the bed spaces in PACU which are currently occupied. 

4. The Patient Name, other demographic and case procedure columns reflect 
these database items for a single case. The database can be populated with 
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this data using an HL7 interface from the Hospital Information System 
(HIS). 

5. The Last Attending and Last User columns reflect the last Attending to 
sign in to a case and the last or current user of the case based on user login. 
These columns thus reflect who should be called to access the caregivers 
for a case. 

6. The Last User column can also provide the feature of an active element 
looking for data entered by users to reflect their 'break' reliefs, i.e. coffee 
and lunch breaks as shown in segment 1801 of Figure 18. 

The servlet can also look for database events entered by users to indicate 
'breaks' and if found, displays persistently the most recent event and time 
in the Last User column. In this way, an administrator can see at a glance 
who has been given 'break relief in a suite of operating rooms. This can 
be a powerful feature for management of staff, as this may otherwise be a 
haphazard process involving multiple telephone calls to rooms. 

7. The Milestone and Time columns display the last entered milestone event 
and the time it occurred. Milestone events are configured at installation to 
be those events entered by the clinical user which reflect the time course of 
a case. As the page autorefreshes, the user can see individual cases 'march' 
through their milestones, giving an immediate impression of the exact 
clinical status of the case. This again can be a powerful tool for 'at-a- 
glance' administration of an operating room suite. Milestones are steps of 
a surgery occurring in the operating room while the case status is "In 
Progress", and milestones can include (but are not limited to): patient 
arrival in preop holding; start of anesthesia care; patient leaves preop 
holding; patient arrives in OR; anesthesia induction; anesthesia ready; 
surgical incision; surgical timepoints; aortic crossclamp on; CPB on; aortic 
crossclamp off; CPB off; surgeon closing wound; end of surgery; 
anesthesia extubation; patient arrives in PACU (recovery area); end of 
anesthesia care; and discharge from PACU; or free text entered by a care 
provider. 

8. The Operating Room Status Page can also include one or more alert icons. 
The alert icon can be used as a link to textual information relating to 
specific information for one of the patients scheduled for operation. An 
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alert icon, for example, can be used to indicate an allergy, an event in a 
previous operation, an outcome of a previous operation, or any other 
information that would be useful to know before performing an operation 
and/or administering anesthesia. More particularly, a preoperative 
screening can be performed prior to the scheduled operation, information 
obtained during the preoperative screening can be entered into a screening 
database, and alert icons can be generated based on information entered 
into the screening database. In the alternative, events and/or outcomes 
from anesthesia records of prior operations can be used to generate alert 
icons on the Operating Room Status Page. 
Operations for generating the Operating Room Status Page at the application 
server for display at a client device are illustrated in Figure 19. The application server 
can initialize the servlet CasesByUser by request from a browser of a remote client 
device at block 1901; get user/group parameters at block 1903, and initialize a JDBC 
connection with a relational database of an anesthesia information system at block 
1905. At block 1907, stored SQL procedures are run to retrieve data form the 
relational database of the anesthesia information system and to build tables of the data 
for the Status Page. The result set is opened at block 1909, and a table header is built 
in a row using HTML at blocks 1911 and 1912. For each case to be displayed by the 
status monitor at block 1913, the case data is retrieved at block 1915, and an HTML 
row is built at block 1916. Once HTML rows have been built for the header and for 
all rows, the output HTML is returned to the calling browser of the remote client at 
block 1917. 

As shown in Figure 20, the Anesthesia Record Page 1317 can display a 
representation of an anesthetic record using tabular, columnar and interactive 
graphical formatting of the data. It is the result of the output of the servlet 
CasesByCaseid and is accessed by following a link from the Anesthetic Record 
Search Result Page. 

An overall impression of this page can be that of a classic anesthesia record in 
the format to which anesthesia staff is universally familiar. Some compromises may 
have to be made due to the limitations of the HTML medium and for the sake of 
application speed, but the result can be remarkably effective. 

A rearrangement has been made in the ordering of the major categories of data 
compared to the classical record. The case events 2001 are placed first after 
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demographics 2003, instead of the case drugs, and the case events section is followed 
by a graphical display 2005 of the recorded vital signs and event bar. The case drugs 
2007 are moved lower in the display after the graphical display. The gases and fluids 
2009 and Labs and perioperative totals 2011 can follow the case drugs. This 
rearrangement reflects a departure from the functionality of the classic anesthetic 
record, which is optimized for data entry, whereas the web is optimized for data 
viewing. Putting the case events near the top of the page makes the course of the 
anesthetic immediately apparent to the clinical user, without having to scroll down to 
the rest of the case. Because a major function of a web-based anesthesia record is the 
rapid lookup and evaluation of old records, this can be a worthwhile change. It also 
partitions the page into "event" and "data" halves, with the rest of the page below 
Events being devoted to the display of automatic, graphical and technical data 
optimized for more detailed review. Alternatively, a conventional arrangement of the 
data can be used. 

Another feature of the page is the use of a 'newspaper column' format to 
compact the data into a relatively short scrollable page, while maintaining readability. 
Because the 'MULTICOL 5 HTML command is specific only to Netscape, it was not 
used, so the columnar formatting in ORview is performed in the servlet using a 
combination of Java and HTML code. 

Another feature of the page is its ability to display a "real-time 55 view of the 
anesthetic record by using its autorefresh feature. A record autorefreshing every 
minute is effectively a real time view of the anesthetic or P ACU record, so that 
ORview can be used to remotely monitor live cases over the internet. In fact, the 
graphical representation of the monitored vital sign data is so much more effective 
than that of most anesthesia information systems, that clinical users may elect to use 
ORview as a supplement view of case in the operating room as the case is running, 
using their Anesthesia Information System only for data entry, for which it is 
optimized. 

An Anesthesia Record Page according to embodiments of the present invention 
can include the following field features: 

1 . Customizable header by institution, configured using web.xml. 

2. Customizable logo by institution, configured using web.xml. (shown here 
is the spinning Duke shield). 
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3. Case Demographics with automatically resizing fields and calculated 
values taken from the database. 

4. Case staffing data drawn from the database, 

5. Case diagnosis and procedure fields drawn from the database. 

6. Case Events. Here a newspaper column format is used to display 2 
columns of the events associated with the case. The Columns resize to 
match the quantity of data. 

7. The Monitored Vital Sign Graphic. This feature of ORview is the output of 
the ImageServer software as described in a previous section. The Popchart 
Image Server Embedder (PCISE) inserts an HTML reference to an image 
at this point in the page, and the web browser loads the image. The image 
is of Macromedia Shockwave Flash format, a vector graphic format which 
has excellent printing, rapid rendering, small size and interactivity as some 
of its properties. To view the graphic, the web-browser uses the 
Shockwave Flash Plug-in, for which a download reference is included in 
the embedded HTML, and which generally is included by default in all 
current major Browser installations. 

Anesthesia records traditionally chart vital sign data graphically, and this 
feature of ORview does the same. It charts all the vital signs for a case in 
an image of 975 x 600 pixels. A significant feature of the graph is the 
custom 3D "Event Bar" 2101a and 2101b as shown in Figures 21 and 22. 
The 3D Event Bar is a representation of Events and Drugs in the 
perioperative record charted as a symbol 2103 against time at the point of 
the event. Multiple events in the same minute period are depicted by a 
vertical step in the y-axis, so that none of the symbols in a group are 
hidden by surrounding symbols. The third dimension to this feature is that 
the text events themselves are pop-up labels 2105 associated with the 
symbols, viewable by touching the symbols 2103 as a hot-spot, as shown 
in Figure 22. 

In this way, ORview is able to represent a great deal of data in compact 
format, such that the entire record for a complex case can be squeezed into 
a graphic across a single screen and yet still allow the event and drug time 
course to be clear. This can be a great advantage of ORview over 
traditional Anesthesia Information Systems, which are generally optimized 
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for data entry and whose graphical representation of vital signs and drugs 
may often span several pages to the detriment of the overall view of the 
case. This is another reason why ORview may become preferred for 
reviewing anesthetic case data. The chart 2301 of Figure 23 illustrates this 
by showing how ORview represents the trended vital signs data from a 16 
hour case. 

8. The Drugs Display and Fluids Display follow the graphical data of Figure 
20. Again, the newspaper column format is used to compact this 
information and display it in logical time sequence. Four columns are used 
for compactness, while retaining the aesthetic appeal of the page. 

9. The Labs and Totals Display follows the Gases and Fluids Display of 
Figure 20. Three columns are used, but these are no longer newspaper 
columns as the data is of three different types. For drug and fluid totals, a 
simple descending list is used. For Labs, a complex list structure is 
displayed, with all the labs associated with a single time period 
concatenated into a string in a format very familiar to anesthesia staff. 

Operations for generating an anesthesia record page at an application server 
for display at a remote client device are illustrated in Figure 24. The application 
server can initialize the servlet CasesByCaselD in response to a request from a 
browser of an authorized client device at block 2401. The CaselD parameters can be 
obtained at block 2403, and the JDBC connection with the database server of the 
anesthesia information system can be initialized at block 2405. The case 
demographics, case staff, case procedures, and case events can be obtained from the 
AIS database server at blocks 2407, 2409, 2411, and 2413, and organized into 
scrollable results sets at block 2415. The demographics and Events columns are built 
in an HTML format as shown at blocks 2417 and 2419. Vital signs are requested and 
retrieved at blocks 2423 and 2425, and loaded into the PCISEemedder at block 2427. 
The PCIS script including the vital signs is built using the image server to provide an 
embedded HTML image reference as shown at blocks 2429, 2431, and 2433. Totals 
for drugs, gases and fluids, and labs and perioperative are obtained at blocks 2435 and 
2437, and a scrollable result set is built according to the HTML format as illustrated at 
blocks 2439 and 2441. The HTML output for the completed anesthesia record page is 
returned to the browser of the requesting client device. 
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Security and the maintenance of patient confidentiality can be an element of 
ORview. The security features of ORview can include up to three or more 
components:- 

1 . Strong Data Encryption; 

2. User Authentication; and 

3. User Audit. 

Data encryption features of ORview have been extensively discussed 
elsewhere in this document, but to recap these features may include RS A_5 strong 
public key/private key data encryption using the Secure Sockets Layer (SSL), used 
extensively for privacy on the Internet. Effectively, hacking or sniffing patient data 
between its source, the Tomcat application server, and the client Internet browser may 
be difficult or impossible. 

These features, however, may not address a vulnerability between the 
application server and the database over the Tabular Data Stream (TDS) used by 
JDBC type 4 connections. This is moderately indecipherable, but can be read. 
However, in an individual hospital the application server and database server can be 
on the same intranet, so the TDS datastream can be no more vulnerable than any other 
text-based messaging system carrying patient data, such as HL7. The TDS 
vulnerability may become important if ORview is configured to access a remote 
database. For this situation, strong encrypted JDBC solutions exist, using JDBC type 
3 drivers which utilize a middle tier datasource on the server and which encrypts the 
JDBC data interchange. A solution may be offered by IDS as discussed at 
http://www.idssoftware.com/jdbcdrv.html. 

ORview can be configured for encrypted JDBC in the circumstance of serving 
schedules and anesthetic records to multiple hospitals over the Internet, and accessing 
multiple remote databases. A block diagram 2501 of security structures according to 
embodiments of the present invention are illustrated, for example, in Figure 25. 

ORview can use the BASIC authentication (user/password) schema, 
administered using Tomcat's security realm model. This authentication can involve 
setting up a database of users with the data model illustrated in Figure 26. 

The user realm for ORview is maintained in a separate Sybase Adaptive 
Server Anywhere database which manages the user rights to a single hospital's users. 
The settings for the realm are made on Tomcat's server.xml file. Multiple realms are 
possible for ORview, governing multiple different hospitals' security models. 
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The modus operandi of BASIC authentication is a password challenge, as 
shown in the screen 2701 of Figure 27. However, Tomcat may not provide a way of 
administering user names and passwords, so this mechanism can be built-in to 
ORview. 

Users can be assigned a username and password upon request by the system 
administrator. This effectively creates a user_name, userjpassword, and user_role in 
the user database. Users are assigned a starter password like "welcome" and then 
asked to change it on first login. 

ORview provides a "Change Password Page" 2801 as shown in Figure 28 
which enables the user to change their password in a valid manner. The output of this 
page is sent to a servlet, orview.changepswd which administers and updates the fields 
in the user database. Successful attempts to change password lead the user back to the 
main Welcome Page of ORview. Unsuccessful attempts to change a password are met 
with an error message, and the requirement to try again. 

For any clinical application to maintain HIPPA compliance, it must have some 
mechanism of user audit. The very strengths of ORview's ability to make all patient 
data viewable on the Internet, may also be a considerable security weakness if users 
with appropriate access rights are using or viewing data inappropriately. This is called 
"peeking", and would include, for example, a colleague looking up a girlfriend's 
anesthesia record without her consent. The security principle here is that users should 
only have access to records and data from patients with whom they have a clinical 
relationship. However, this may be difficult or impossible to administer rigidly, as 
often caregivers will appropriately want to look up information on patients before 
they have actually created any record of the event in any hospital system. 

One commonly used fallback method is to audit who is looking at what, and 
reprimand users whose use patterns are inappropriate. ORview uses this method, 
keeping an audit table of all database access of the anesthesia record in the table 
"audit_user", with a schema as shown in Figure 29. 

The onus then becomes one of auditing the audit table. However, statistical 
analysis of the audit table should rapidly show any inappropriate use, whilst providing 
an audit trail of individual accesses. 

Embodiments of the invention can also use sophisticated user management 
schemas to organize registration and passwords. The diagram of Figure 30 illustrates 
the password schema of ORview, which makes extensive use of Java Server Pages 
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(JSP) technology. A new user can be assigned a temporary user name and password, 
and the temporary user name and password can be provided by the system 
administrator via e-mail. At the login page 3001, the user enters the appropriate 
username and password, either permanent if an existing user or temporary if a new 
user. At block 3003, the application server determines if the username and password 
are authorized as an existing user, normal system access is allowed by providing the 
Choices Page 3005. If the username and password are authorized as a new user, a 
registration process is initiated at block 3007. If the registration process is 
successfully completed at block 3009, a permanent username and password are 
assigned to the new user at block 3011, the permanent username and password are 
stored in the SQL user database 3013, and the user can be prompted to login with the 
permanent password at 3001. 

Figure 30 also shows that the Choices Page can be used to initiate a change of 
password for an existing user. If a password change is requested at the Choices Page 
3005, the password change procedure can be performed at block 3015. In particular, 
the user can select a new password, the new password can be saved in the SQL user 
database, and the user can be presented with the login request 3001 to login with the 
new password. 

As described above, embodiments of the invention can exploit the power of 
the Internet in the perioperative environment. Embodiments of the invention can 
include, among other things, one or more of the following: 

1 . A Live Web-Based operating room and perioperative suite Status Monitor, 
that can be served robustly using data encryption and thereby opening the 
medium of the Internet to this practical clinical use. 

2. A Perioperative Anesthetic Record viewable using an Internet Browser 
that can be served robustly using data encryption thereby opening the 
medium of the Internet to this practical clinical use. 

3. The Representation of Monitored Data as a Graphic over the Internet that 
can be served robustly using an image server and also encrypted. 

4. The representation of the Time course of Events and Drugs using a "3D 
event bar." 

5. The use of middle tier, Java servlet and JavaServer Pages technology 
running on an Application Server to generate an Anesthetic Record and 
Perioperative Schedule. 
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Moreover, various terms used in this disclosure are further defined as indicated 
below: 

1. Anesthesia Information Systems (AIS) are computer systems which record 
and display data gathered in the perioperative period. Data is either input 
by anesthesia, clerical or nursing staff directly into the system, or is 
automatically acquired from patient monitoring devices. 

2. The perioperative period is the interval of time associated with a single 
surgical encounter, from the time of the decision to take a patient to 
surgery until the discharge of the patient home from hospital. This 
definition could also include outcome data gathered from the patient after 
discharge with respect to the associated surgical encounter. 

3. JDBC is the abbreviation for Java Data Base Connectivity. A JDBC driver 
is a set of Java classes that manage connectivity to a database. ORview 
uses the Sybase JConnect driver, but is configurable to use any JDBC 
driver to any JDBC 2.0 enabled database (all the main RDBMs) 

4. CDR is the abbreviation for Common Data Repository, a hospital database 
that aspires to collect all patient related data. A CDR is uaually heavily 
interfaced to other hospital information systems, which send it their data. 
Usually this consists of lab tests, clinic notes, EKG reports and the like. A 
CDR usually has an associated front-end "browser" application which acts 
as a patient-centric window on the data. 

In overview, embodiments of the present invention relate to providing 
scheduling information and/or medical records relating to surgical care. As will be 
appreciated by one of skill in the art, the present invention may be embodied as 
methods, data processing systems, and/or computer program products. Accordingly, 
the present invention may take the form of an entirely hardware embodiment, an 
entirely software embodiment or an embodiment combining software and hardware 
aspects. Furthermore, the present invention may take the form of a computer program 
product on a computer-usable storage medium having computer-usable program code 
embodied in the medium. Any suitable computer readable medium may be utilized 
including, but not limited to, hard disks, CD-ROMs, optical storage devices, and 
magnetic storage devices. 

Computer program code for carrying out operations of the present invention 
may be written in an object oriented programming language such as JAVA®, 
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Smalltalk or C++. The computer program code for carrying out operations of the 
present invention may also be written in conventional procedural programming 
languages, such as "C", or in various other programming languages. Software 
embodiments of the present invention do not depend on implementation with a 
particular programming language. In addition, portions of program code may execute 
entirely on one or more data processing systems. 

The present invention is preferably practiced within a client/server 
programming environment. As is known by those skilled in this art, client/server is a 
model for a relationship between two computer programs in which one program, the 
client program, makes a service request from another program, the server program, 
which fulfills the request. Relative to the Internet, a Web browser is a client program 
that requests services (the sending of Web pages or files) from a Web server (which 
technically is called a Hypertext Transport Protocol or HTTP server) in another 
computer somewhere on the Internet. 

An implementation of the present invention may use the Application Service 
Provider (ASP) model. As is understood by those of skill in the art, an ASP is an 
entity that offers individuals and enterprises access over the Internet (or other 
communications network) to applications and related services that would otherwise 
have to be located in local computers and/or devices. 

As is known to those with skill in this art, client/server environments may 
include public communications networks, such as the Internet, and private 
communications networks often referred to as "intranets" and "extranets." The term 
"Internet" shall incorporate the terms "intranet" and "extranet" and any references to 
the Internet shall be understood to mean a communications network of any type, 
including intranets and/or extranets. 

Further embodiments of the present invention will now be discussed with 
regard to the flow charts of Figures 31-35. Embodiments of the present invention, for 
example, can be used to provide a status monitor for a suite of operating rooms 
according to the operations illustrated in Figure 31 to provide a status monitor display 
such as that illustrated in Figure 17. As shown in Figure 31, operation scheduling 
information can be retrieved at block 3101. More particularly, the operation 
scheduling information can be retrieved for scheduled operations in a plurality of 
operating rooms in a designated hospital area over a predetermined time period, and 
the scheduling information can include a patient identification and a procedure 
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identification. For example, operation scheduling information can be retrieved for 
operations scheduled in one or more of a plurality of areas such as those areas 
identified in Figure 14 for a particular day. The scheduling information can thus 
provide information for fields of the columns of Figure 17 labeled "Division", "Date", 
"Pt Name" (patient name), "PtHxNo" (patient history number), "Age", and/or 
"Procedure". The scheduling information can be retrieved from a scheduling 
database. 

At block 3103, current status information can be retrieved for scheduled 
operations while scheduled operations are in progress, and the current status 
information can be selected from one of a plurality of milestones of a surgical 
operation. The current status information can thus provide information for the fields 
of column of Figure 17 labeled "Milestones". By retrieving current status information 
while operations are in progress, a status monitor can provide near real-time 
information. Moreover, the current status information can be retrieved from data 
entered into electronic data entry systems in the respective operating rooms. The 
current status information, for example, can be retrieved from data entered into 
anesthesia information system workstations. 

A table of scheduled operations over the predetermined time period can be 
built at block 3105. For each scheduled operation, the table can include respective 
patient and procedure identifications. The patient identification, for example, can be a 
patient name and/or a patient history number shown in Figure 17 as the columns 
labeled "Pt Name" and "PtHxNo". The table can also include the current status 
information such as the information shown in the column of Figure 17 labeled 
"Milestones" and times the respective "Milestones" were entered. The information of 
the table can be displayed at block 3107. 

Scheduling information can thus be entered into an electronic scheduling 
system such that no additional scheduling information is entered for a particular day 
after some cut off time before the first scheduled operation that day. For example, the 
cut off time may be defined as being some time before the end of working hours the 
previous business day. Accordingly, the schedule for a given day can be set after the 
cut off the day before. The previously entered scheduling information can then be 
used as a base of information for the operating room status monitor during the day. 
This scheduling information can then be updated during the day in near real-time with 
data entered by surgical staff during surgery into workstations in the operating rooms 
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so that the status monitor can be used to manage a plurality of operating rooms in near 
real-time. Current status information, for example, may be updated once a minute. 

As long as operations are continued at block 3109, the status monitor can 
maintain the display. When it is time to refresh the table and display with new current 
status information at block 3111, any new current status information can be retrieved 
at block 3103. The table can be rebuilt including any new current status information 
at block 3105, and the updated table can be displayed at block 3107. Refresh can be 
initiated at block 3111 periodically, such as at one minute intervals, and the refresh 
interval can be programmed by a user. Alternately, refresh can be initiated at block 
3111 when it is detected that new current status information is available. In addition, 
refresh can be initiated at block 3111 in response to a user request for refresh. 

As discussed above, a plurality of operating rooms can be equipped with a 
respective electronic data entry system wherein retrieving current status information 
can include retrieving current status information entered into the respective electronic 
data entry system. More particularly, one or more of the data entry systems can be an 
anesthesia information system workstation. In addition to operating rooms, the 
hospital area can also include a plurality of preoperative preparation areas and 
postoperative recovery areas and wherein the operating rooms, preoperative 
preparation areas, and postoperative recovery areas is equipped with a respective 
electronic data entry system. Accordingly, retrieving current status information at 
block 3103 can include retrieving current status information entered into the 
respective electronic data entry system in one or more of the operating rooms, 
preoperative preparation areas, and/or postoperative recovery areas. 

The scheduling information retrieved at block 3101 and the table for each of 
the scheduled operations can also include at least one of an operating room 
identification (can be displayed under "OR Name 11 in Figure 17), a scheduled start 
time (can be displayed under "Case Status" in Figure 17), an assigned physician (can 
be displayed under "Last Attending" and/or "Last User" of Figure 17), and a patient 
age (can be displayed under "Age" in Figure 17). In addition, the patient 
identification for each scheduled operation can include at least one of a patient name 
(can be displayed under "Pt Name" in Figure 17) and a patient identification number 
(can be displayed under "PtHxNo" in Figure 17). Moreover, the current status 
information retrieved at block 3103 can include a surgical event (can be displayed 
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under "Milestone" in Figure 17) and a time of the surgical event (can be displayed 
under "Time" in Figure 17). 

The status monitor of Figures 17 and 3 1 can be used by a physician to obtain 
additional information regarding a surgical operation scheduled to be performed. For 
example, selection of a patient identification from the table of scheduled operations 
can be accepted. The selection of a patient identification, for example, can be entered 
by a user using a mouse or roller ball coupled with a screen displaying the table of 
scheduled operations, using a touch sensitive surface of the screen displaying the table 
of scheduled operations, a keypad, or other input means known to those having skill 
in the art. 

Responsive to accepting selection of the patient identification, at least one case 
identification corresponding to the patient identification can be retrieved and 
displayed, as shown, for example, in Figure 16. In this context, a case identification 
can be a unique identification of a surgical operation performed, so that a different 
case identification is assigned to every surgical operation performed in a hospital, and 
so that a patient may have multiple case numbers associated therewith if multiple 
surgical operations have been performed in that hospital on that patient. In other 
words, a patient identification (such as "PtHxNo" of Figure 17 and/or "HxNo" of 
Figure 16) uniquely identifies the patient, and the case identification (such as "Case 
ID" of Figure 16) uniquely identifies each of the surgical operations. 

As shown in Figure 16, selection of one patient identification from a displayed 
table of scheduled operations (such as that shown in Figure 17) may result in 
retrieving and displaying a plurality of case identifications (such as that illustrated in 
Figure 16). Selection of one of the plurality of case identifications can then be 
accepted from a user. As discussed above, user input can be provided using a mouse 
and/or roller ball coupled with a screen displaying the plurality of case identifications, 
using a touch sensitive surface of a screen displaying the plurality of case 
identifications, or using other input means known to those having skill in the art. 

Responsive to accepting selection of the case identification, a medical record 
corresponding to the selected case identification for the selected patient identification 
can be retrieved and displayed. Retrieving the medical record can include retrieving 
data making up the medical record from a relational database and building a file of 
data for the medical record as opposed to retrieving a scanned image of a record. 
More particularly, the medical record can be an anesthesia record, and the anesthesia 
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record can include a date of a surgical operation, events occurring during the surgical 
operation, a graphical display of vital signs recorded during the surgical operation, 
and drugs administered during the surgical operation. Moreover, the anesthesia can 
have the format and additional information illustrated in Figure 20. 

Additional embodiments of the present invention, for example, can be used to 
retrieve medical information in an efficient manner according to operations illustrated 
in Figure 32 to provide case identifications such as illustrated in Figure 16. For 
example, scheduling information can be retrieved for all scheduled operations 
meeting predefined criteria at block 3201, wherein the scheduling information for the 
scheduled operations includes a patient identification and a procedure identification. 
The patient identification can include at least one of a patient name and a patient 
identification number, and the scheduling information can additionally include at least 
one of an operating room identification, a scheduled start time, an assigned physician, 
and a patient age. 

A table of all scheduled operations can be built at block 3203, wherein for a 
respective scheduled operation, the table includes the respective patient identification 
and procedure identification, and the table can be displayed at block 3205. The 
predefined criteria, for example, can be defined by the user as all operations 
scheduled for a particular physician on a given day. Accordingly, the table and 
display can include information such as that illustrated in Figure 17 but only for cases 
scheduled for the selected physician. Alternately, the predetermined criteria can be 
defined by the user as all operations scheduled for a particular area of the hospital on 
a given day. Moreover, other criteria and or other time periods may be used. 

The display can be maintained at block 3207 until a user selection is made. 
Selection of one of the patient identifications can be accepted from the table of all 
scheduled operations meeting the predefined criteria at block 3209, and responsive to 
accepting selection of the patient identification, at least one case identification 
corresponding to the patient identification can be retrieved at block 3211. User 
selection can be input through a mouse or roller ball coupled to a screen displaying 
the table, through a touch sensitive surface of a screen displaying the table, or through 
other means known to those having skill in the art. The at least one case identification 
corresponding to the patient identification can then be displayed at block 3213 to 
provide a display such as that illustrated in Figure 16. As discussed above, each case 
identification identifies a different surgical operation performed on the patient. 
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Embodiments of the present invention can thus allow a physician to efficiently 
generate a schedule of the physician's assigned operations for a defined time period, 
and then generate a list of previous operations for a patient listed on the schedule. 
The list of previous operations may be useful to the physician in preparing for a 
particular operation. 

Once case identifications are displayed for a patient, embodiments of the 
present invention allow the physician to obtain medical records such as anesthesia 
records for the different previously performed operations. Information included in 
these medical records may be useful in preparation for the scheduled operation. For 
example, table of case identifications can be maintained at block 3215 until a user 
selection of a case identification is made. Selection of one of the case identifications 
can be accepted and a medical record corresponding to the selected case identification 
for the selected patient identification can be retrieved at block 3217 and displayed at 
block 3219. More particularly, the medical record can be an anesthesia record, and 
the anesthesia record can include a date of a surgical operation, events occurring 
during the surgical operation, a graphical display of vital signs recorded during the 
surgical operation, and drugs administered during the surgical operation. 

The medical record may be displayed until there is use selection at block 3221 
of the previously displayed case identifications. If the user selects to return to the 
previously displayed case identifications, the case identifications can be displayed at 
block 3213, and the user can select a different one of the case identifications at block 
3215 for retrieval and display of a new medical record at blocks 3217 and 3219. 
Accordingly, a physician can efficiently view different medical records for a patient 
in preparation for an operation. 

Alternately, the user may select at block 3223 to return to the previously 
displayed table of scheduled operations at block 3205. A selection and acceptance of 
a new patient identification from the previously generated table can thus be made at 
blocks 3207 and 3209, and new case identifications corresponding to the new patient 
identification can be retrieved and displayed at blocks 3211 and 3213. Medical 
records corresponding to the new case identifications can be selected, retrieved, and 
displayed as discussed above with respect to blocks 3215, 3217, 3219, and 3221. 
Accordingly, a physician can efficiently review medical records from prior operations 
for different patients scheduled for different operations. 
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In addition, a user can select new schedule criteria at block 3225 so that 
different scheduling information is retrieved at block 3201. A physician, for example, 
may first retrieve scheduling information for the next day as discussed above. After 
reviewing the schedule, prior related case identifications, and prior related medical 
records, the physician may choose at block 3225 to retrieve scheduling information 
for another day. Moreover, a supervising physician may choose to generated different 
schedules for the same day for different physicians be supervised. 

When retrieving information according to embodiments of the present 
invention, alerts from pre-operative screenings corresponding to a patient 
identification included in the table of scheduled operations can also be retrieved. 
Moreover, these alerts can be included in and displayed with the table of scheduled 
operations meeting the predefined criteria. The displayed alert may be an alert icon 
providing a link to additional textual information. For example, a preoperative 
screening may be performed a week before the operation, and a particular allergy or 
other useful information may be uncovered at that time. This information may be 
entered into a preoperative screening database such that the step of retrieving 
scheduling information at block 3201 includes retrieving alerts from the preoperative 
screening database. Identification of and access to these alerts may further enhance 
the physician's ability to prepare for scheduled operations. 

Additional embodiments of the present invention, for example, can be used to 
display anesthesia records according to operations illustrated in Figure 33 to provide 
an anesthesia record such as that illustrated in Figure 20. Moreover, the anesthesia 
records can be displayed using a data processing system at a terminal remote from the 
data processing system. For example, entry of information identifying a surgical 
operation can be accepted at block 3301 wherein the information is entered via a 
client device in communication with the data processing system. Anesthesia data 
corresponding to the identified surgical operation can be retrieved at block 3303, and 
an anesthesia record can be built at block 3305 using the retrieved anesthesia data. 
Secure communication of the anesthesia record to the client device can be provided at 
block 3307 for display of the anesthesia record at the client device. 

, More particularly, the anesthesia data can be retrieved from a database (such 
as a relational database) generated by an anesthesia information system including 
workstations in respective operating rooms for data input by surgical staff during 
operations. Each field of the anesthesia record to be built can be populated by 
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retrieving a corresponding field from the database. In other words, anesthesia record 
can be built by retrieving a plurality of data fields from a database. In addition, the 
database can be separate from the data processing system used to build the anesthesia 
record. 

Moreover, the client device can be a terminal such as a personal computer 
remote from the data processing system wherein the client device and data processing 
system are coupled by a network such as the internet. By providing secure 
communication of the anesthesia record from the data processing system to the client 
device, the confidential anesthesia record can be obtained remotely over an unsecured 
network such as the internet. Moreover, the secure communication can be provided 
using encryption as discussed above. 

The resulting anesthesia record can include a date of a surgical operation, 
events occurring during the surgical operation, a graphical display of vital signs 
recorded during the surgical operation, and drugs administered during the surgical 
operation, and the anesthesia record can have a format such as that illustrated in 
Figure 20. Moreover, the anesthesia record can be built and communicated while the 
identified surgical operation is in progress. Accordingly, the progress of a surgical 
operation can be viewed at a client device remote from the operation while the 
operation is taking place in near real-time, for example, to provide consultation from a 
remote location. As shown in Figure 33, if there is updated information for the 
anesthesia record at block 3309, the updated data can be retrieved at block 3303, the 
anesthesia record can be built with the new data 3305, and the anesthesia record can 
be securely communicated at block 3307 for display of the updated anesthesia record 
at the client device. Updated information for the anesthesia record can be provided at 
block 3309, for example, at predetermined time intervals that can be designated by the 
user, such as once a minute. Alternately, updated information can be provided when 
updated information is made available or on user request. As further shown at block 
3311 of Figure 33, a new anesthesia record may be selected such that operations of 
blocks 3301, 3303, 3305, and 3307 are repeated for the new anesthesia record. 

The anesthesia record can include a graphical representation of events 
occurring during the identified surgical operation for display at the client device. The 
graphical representation can include a time line divided into predetermined units of 
time with a plurality of events occurring during a period of time represented by a 
single unit on the time line being represented by respective discreet and 
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distinguishable event icons as illustrated, for example, in Figures 21 and 22. In 
addition, user selection of one of the discrete and distinguishable icons can be 
accepted, and responsive to accepting selection of one of the discreet and 
distinguishable event icons, text identifying the event corresponding to the selected 
discreet event icon can be provided for display at the client device as illustrated, for 
example, in Figure 22. 

Accepting entry of information identifying a surgical operation at block 3301 
can include accepting entry of any information sufficient to identify the surgical 
operation. For example, entry of a patient identification such as a patent name or 
patient identification number may be used to identify the anesthesia record. 
Alternately or in addition, entry of a case identification may be used to identify the 
anesthesia record. Moreover, any of the operations discussed above with regard to 
Figure 32 may be used to identify a particular anesthesia record. Moreover, a boolean 
search may be used to identify a particular anesthesia record. 

In addition, aspects of embodiments discussed above can be combined as 
illustrated, for example, in Figure 34. As discussed, a user can access medical 
information such as anesthesia records and/or surgical operation schedules using a 
remote client device coupled to an application server over a network such as the 
internet. To reduce the risk of unauthorized access, a log-in may be required by the 
application server at block 3401, so that access is only provided if an authorized 
combination of username and password are entered at the client device. Upon 
successful login, the application server can provide a choices page at block 3403 for 
display at the client device. A choices page such at that illustrated in Figure 14 can be 
used providing a choice of a search of anesthesia records or a choice of schedules for 
different hospital areas or physicians. Other choices may also be provided. If the 
user selects searches at block 3407, the application server can proceed to accept user 
input of search criteria at block 3421. Alternately, if the user selects schedules at 
block 3407, the application server can proceed to accept user input of schedule criteria 
at block 3441. 

Upon accepting user input of search criteria at block 3421, the application 
server can generate a list of anesthesia records matching the search criteria at block 
3423 for display at the client device. The list of anesthesia records can be generated 
and displayed, for example, using the format of Figure 16 wherein a case 
identification ("Case ID") identifies each of the anesthesia records. The user may 
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then select one of the anesthesia records, and on accepting the user selection at block 
3425, the anesthesia record can be generated at block 3471. Otherwise, the user may 
elect a new search at block 3427, or the user may elect to go back to the choices page 
at block 3429. 

Generation of the anesthesia record at block 3471 can be performed as 
discussed above with respect to Figure 33. Once a record has been generated and 
displayed, the user may elect to go back to the previously generated list of anesthesia 
records and select another anesthesia record for display. At block 3473, the user may 
elect to go back to the previously generated list of anesthesia records at block 3423. 
Another record may be selected at block 3425, a new search may be selected at block 
3427, or the user can select at block 3429 to go back to the choices page at block 
3403. 

If the user selects schedules at block 3407, the application server can proceed 
with accepting user input of schedule criteria. Moreover, the selection of scheduling 
and the particular scheduling criteria may be provide in a single operation such as 
illustrated in the Choices Page of Figure 14. A schedule is then generated based on 
the schedule criteria at block 3443 for display at the client device. The schedule can 
be generated and displayed according to the format illustrated in Figure 17. 
Moreover, the operation of generating a schedule of block 3443 can be the same as 
that discussed above with regard to the operations of Figure 3 1 . The user can then 
select a patient identification from the displayed schedule at block 3445, and a list of 
anesthesia records can be generated for display at the client device according to a 
format such as that illustrated in Figure 16. 

If one of the records for the patient is selected by the user at block 3447, the 
anesthesia record can be generated at block 3471 for display at the client device 
according to a format such as that illustrated in Figure 20. If a patient is not selected 
at block 3445, the user may elect at block 3453 a new schedule based on new criteria 
to be input at block 3441, or the user may elect at block 3455 to go back to the 
choices page at block 3403. If an anesthesia record is not selected at block 3447, the 
user may elect at block 3449 selection of a new patient from the schedule, selection of 
new schedule criteria at block 3451, or at block 3455 to return to the choices page. 
Once an anesthesia record is generated at block 3473 responsive to user selection of 
information from a schedule, the user may elect at block 3473 generation of the 
schedule at block 3443 for display on the client device. The user can then select the 
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same or a different patient and/or record. The operations of blocks 3443, 3445, and 
3447, and 3471 can be the same as operations discussed above in greater detail with 
regard to Figure 32. 

The operations of Figures 31-34 can be performed by an application server 
3501 in communication with a client device 3503 over a network 3505 such as the 
internet. User input can be provided thought the client device 3503 and network 3505 
to the application server 3501. User input can be provided using a touch sensitive 
screen of the client device, using a mouse or roller ball coupled with the client device, 
using a keyboard at the client device, and/or using other means know to those having 
skill in the art. In addition, the application server 3501 can obtain data from database 
servers of one or more information systems such as an anesthesia information system 
3507, a hospital scheduling system 3509, and/or a preoperative screening system 
3511. Data used to build an anesthesia record, for example, can be obtained from a 
database server of anesthesia information system 3507 including anesthesia 
workstations in operating rooms. Data used to build schedules can be obtained from a 
database server of hospital scheduling system 3509, and data used to provide alerts 
can be obtained from a database server of a preoperative screening system 3511. 

Methods, systems, and computer program products according to embodiments 
of the present invention can thus be implemented separate from other hospital 
information systems such that only a data connection to the other hospital information 
systems is required. In the alternative, methods, systems, and computer program 
products according to embodiments of the present invention can be integrated in 
whole or in part with one or more hospital systems. For example, methods, systems, 
and computer program products according to embodiments of the present invention 
can be integrated in whole or in part with an anesthesia information system such as 
the Saturn Information System produced by Draeger. 

Moreover, embodiments of the present invention have been discussed, by way 
of example, with reference to anesthesia records. Embodiments of the present 
invention, however, may be applied to other medical records. For example, 
embodiments of the present invention may be used with Intensive Care Unit (ICU) 
records. 

The foregoing is illustrative of embodiments of the present invention and is 
not to be construed as limiting thereof. Although a few exemplary embodiments of 
this invention have been described, those skilled in the art will readily appreciate that 
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many modifications are possible in the exemplary embodiments without materially 
departing from the novel teachings and advantages of this invention. Accordingly, all 
such modifications are intended to be included within the scope of this invention as 
defined in the claims. Therefore, it is to be understood that the foregoing is illustrative 
of the present invention and is not to be construed as limited to the specific 
embodiments disclosed, and that modifications to the disclosed embodiments, as well 
as other embodiments, are intended to be included within the scope of the appended 
claims. The invention is defined by the following claims, with equivalents of the 
claims to be included therein. 
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That Which Is Claimed Is: 

1. A method of displaying operation scheduling information for a hospital 
surgical area including a plurality of operating rooms, the method comprising: 

retrieving scheduling information for scheduled operations in the plurality of 
operating rooms of the hospital area over a predetermined time period wherein the 
scheduling information for respective scheduled operations includes a patient 
identification and a procedure identification; 

retrieving current status information for at least one of the scheduled 
operations while in progress wherein the current status information is selected from a 
plurality of milestones of a surgical operation while in progress; and 

providing a table of scheduled operations over the predetermined time period 
for display at a client device, wherein for respective scheduled operations, the table 
includes the respective patient identification and procedure identification wherein the 
table further includes the current status information. 

2. A method according to Claim 1 wherein respective ones of the plurality of 
operating rooms are equipped with a respective electronic data entry system wherein 
retrieving current status information comprises retrieving current status information 
entered into a respective electronic data entry system. 

3. A method according to Claim 2 wherein at least one of the data entry 
systems comprises an anesthesia information system workstation. 

4. A method according to Claim 1 wherein the hospital area further includes a 
plurality of preoperative preparation areas and postoperative recovery areas and 
wherein the operating rooms, preoperative preparation areas, and postoperative 
recovery areas are equipped with respective electronic data entry systems, and 
wherein retrieving current status information comprises retrieving current status 
information entered into a respective electronic data entry system. 

5. A method according to Claim 1 wherein retrieving current status information 
comprises retrieving current status information at regular intervals, the method further 
comprising: 

38 



WO 03/025703 



PCT/US02/29354 



refreshing the table on receipt of new current status information and 
displaying the refreshed table. 

6. A method according to Claim 1 wherein the scheduling information and the 
table for each of the scheduled operations further includes at least one selected from 
the group consisting of an operating room identification, a scheduled start time, an 
assigned physician, and a patient age. 

7. A method according to Claim 1 wherein the patient identification for a 
scheduled operation includes at least one selected from the group consisting of a 
patient name and a patient identification number. 

8. A method according to Claim 1 the current status information includes a 
surgical event and a time of the surgical event. 

9. A method according to Claim 1 further comprising: 

accepting selection of a patient identification from the table of scheduled 
operations; 

responsive to accepting selection of the patient identification, retrieving at 
least one case identification corresponding to the patient identification; and 

displaying the at least one case identification corresponding to the patient 
identification. 

10. A method according to Claim 9 wherein the at least one case identification 
comprises a plurality of case identifications, the method further comprising: 

accepting selection of one of the case identifications; 

responsive to accepting selection of the case identification, retrieving a 
medical record corresponding to the selected case identification for the selected 
patient identification; and 

displaying the medical record. 

1 1 .A method according to Claim 1 0 wherein the medical record comprises an 
anesthesia record. 
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12. A method according to Claim 1 1 wherein the anesthesia record comprises a 
date of a surgical operation, events occurring during the surgical operation, a 
graphical display of vital signs recorded during the surgical operation, and drugs 
administered during the surgical operation. 

13. A method of retrieving medical information comprising: 
retrieving scheduling information for scheduled operations meeting a 

predefined criteria wherein the scheduling information for the scheduled operations 
includes a patient identification and a procedure identification; 

providing a table of scheduled operations meeting the predefined criteria for 
display at a client device wherein for each scheduled operation, the table includes the 
respective patient identification and procedure identification; 

accepting selection of one of the patient identifications from the table of 
scheduled operations meeting the predefined criteria; and 

responsive to accepting selection of the patient identification, retrieving at 
least one case identification corresponding to the patient identification for display at 
the client device. 

14. A method according to Claim 1 3 wherein the at least one case 
identification comprises a plurality of case identifications, the method further 
comprising: 

accepting selection of one of the case identifications; and 

responsive to accepting selection of the case identification, retrieving a 

medical record corresponding to the selected case identification for the selected 

patient identification for display at the client device. 

15. A method according to Claim 14 wherein the medical record comprises an 
anesthesia record. 

16. A method according to Claim 1 5 wherein the anesthesia record comprises a 
date of a surgical operation, events occurring during the surgical operation, a 
graphical display of vital signs recorded during the surgical operation, and drugs 
administered during the surgical operation. 
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17. A method according to Claim 13 wherein retrieving scheduling information 
for scheduled operations meeting a predefined criteria comprises retrieving 
scheduling information for operations scheduled within a predetermined time period 
for an area of a hospital. 

18. A method according to Claim 13 wherein retrieving scheduling information 
for scheduled operations meeting a predefined criteria comprises retrieving 
scheduling information for operations scheduled with a designated physician within a 
predetermined time period. 

19. A method according to Claim 13 wherein the scheduling information and 
the table for each of the scheduled operations further includes at least one selected 
from the group consisting of an operating room identification, a scheduled start time, 
an assigned physician, and a patient age. 

20. A method according to Claim 13 wherein the patient identification for each 
scheduled operation includes at least one selected from the group consisting of a 
patient name and a patient identification number. 

2 LA method according to Claim 13 further comprising: 
retrieving an alert from a pre-operative screening corresponding to a patient 
identification included in the table of scheduled operations meeting the predefined 
criteria, wherein displaying the table of scheduled operations meeting the predefined 
criteria includes displaying an indication of the alert. 

22.A method of displaying anesthesia records comprising the following 
performed by a data processing system: 

accepting entry of information identifying a surgical operation wherein the 
information is entered via a client device in communication with the data processing 
system; 

retrieving anesthesia data corresponding to the identified surgical operation; 
building an anesthesia record using the retrieved anesthesia data; and 
providing secure communication of the anesthesia record to the client device 
for display of the anesthesia record at the client device. 
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23 .A method according to Claim 22 wherein the anesthesia record comprises a 
date of a surgical operation, events occurring during the surgical operation, a 
graphical display of vital signs recorded during the surgical operation, and drugs 
administered during the surgical operation. 

24.A method according to Claim 23 wherein providing secure communication 
of the anesthesia record comprises providing secure communication of the anesthesia 
record corresponding to the identified surgical operation while the identified surgical 
operation is in progress. 

25 .A method according to Claim 24 further comprising: 
after providing secure communication of the anesthesia record to the client 
device, retrieving updated information including at least one selected from the group 
consisting of a new event occurring during the surgical operation, a new measurement 
of vital signs, and a new drug administered; and 

after retrieving the updated information, providing secure communication of 
the updated information to the client device for display of an update of the anesthesia 
record at the client device while the identified surgical operation is in progress. 

26. A method according to Claim 22 wherein the anesthesia record comprises a 
graphical representation of events occurring during the identified surgical operation 
for display at the client device, the graphical representation including a time line 
divided into predetermined units of time with a plurality of events occurring during a 
period of time represented by a single unit on the time line being represented by 
respective discreet and distinguishable event icons. 

27. A method according to Claim 26 further comprising: 

accepting selection of one of the discreet and distinguishable event icons; and 
responsive to accepting selection of one of the discreet and distinguishable 

event icons, providing text identifying the event corresponding to the selected discreet 

and distinguishable event icon for display at the client device. 



42 



WO 03/025703 PCT/US02/29354 

28. A method according to Claim 22 wherein accepting entry of information 
identifying a surgical operation comprises accepting entry of a selection of a patient 
identification. 

29. A method according to Claim 28 wherein the patient identification includes 
at least one selected from the group consisting of a patient name, and a patient 
identification number. 

30. A method according to Claim 22 wherein accepting entry of information 
identifying a surgical operation comprises accepting entry of a selection of a case 
identification. 

31. A data processing system that facilitates display of operation scheduling 
information for a hospital surgical area including a plurality of operating rooms, the 
data processing system comprising: 

means for retrieving scheduling information for scheduled operations in the 
plurality of operating rooms of the hospital area over a predetermined time period 
wherein the scheduling information for the scheduled operations includes a patient 
identification and a procedure identification; 

means for retrieving current status information for at least one of the 
scheduled operations while in progress wherein the current status information is 
selected from a plurality of milestones of a surgical operation while in progress; and 

means for providing a table of scheduled operations over the predetermined 
time period for display at a client device wherein for a scheduled operation, the table 
includes the respective patient identification and procedure identification wherein the 
table further includes the current status information. 

32. A data processing system according to Claim 31 wherein the plurality of 
operating rooms are equipped with a respective electronic data entry system wherein 
the means for retrieving current status information comprises means for retrieving 
current status information entered into the respective electronic data entry system. 

33. A data processing system according to Claim 32 wherein at least one of the 
data entry systems comprises an anesthesia information system workstation. 
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34. A data processing system according to Claim 3 1 wherein the hospital area 
further includes a plurality of preoperative preparation areas and postoperative 
recovery areas and wherein the operating rooms, preoperative preparation areas, and 
postoperative recovery areas are equipped with respective electronic data entry 
systems, and wherein the means for retrieving current status information comprises 
means for retrieving current status information entered into the respective electronic 
data entry system. 

3 5. A data processing system according to Claim 31 wherein the means for 
retrieving current status information comprises means for retrieving current status 
information at regular intervals, the data processing system further comprising: 

means for refreshing the table on receipt of new current status information and 
means for providing the refreshed table for display at the client device. 

3 6. A data processing system according to Claim 31 wherein the scheduling 
information and the table for the scheduled operations further includes at least one 
selected from the group consisting of an operating room identification, a scheduled 
start time, an assigned physician, and a patient age. 

37. A data processing system according to Claim 31 wherein the patient 
identification for a scheduled operation includes at least one selected from the group 
consisting of a patient name and a patient identification number. 

3 8. A data processing system according to Claim 31 the current status 
information includes a surgical event and a time of the surgical event. 

39. A data processing system according to Claim 3 1 further comprising: 
means for accepting selection of a patient identification from the table of 

scheduled operations; 

means, responsive to accepting selection of the patient identification, for 
retrieving at least one case identification corresponding to the patient identification; 
and 
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means for providing the at least one case identification corresponding to the 
patient identification for display at the client device. 



40. A data processing system according to Claim 39 wherein the at least one 
case identification comprises a plurality of case identifications, the data processing 
system further comprising: 

means for accepting selection of one of the case identifications; 

means, responsive to accepting selection of the case identification, for 
retrieving a medical record corresponding to the selected case identification for the 
selected patient identification; and 

means for providing the medical record for display at the client device. 

41. A data processing system according to Claim 40 wherein the medical 
record comprises an anesthesia record. 

42. A data processing system according to Claim 41 wherein the anesthesia 
record comprises a date of a surgical operation, events occurring during the surgical 
operation, a graphical display of vital signs recorded during the surgical operation, 
and drugs administered during the surgical operation. 

43 .A data processing system that retrieves medical information comprising: 

means for retrieving scheduling information for scheduled operations meeting 
a predefined criteria wherein the scheduling information for the scheduled operations 
includes a patient identification and a procedure identification; 

means for providing a table of scheduled operations meeting the predefined 
criteria for display at a client device wherein for each scheduled operation, the table 
includes the respective patient identification and procedure identification; 

means for accepting selection of one of the patient identifications from the 
table of scheduled operations meeting the predefined criteria; and 

means, responsive to accepting selection of the patient identification, for 
retrieving at least one case identification corresponding to the patient identification 
for display at the client device. 
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44.A data processing system according to Claim 43 wherein the at least one 

case identification comprises a plurality of case identifications, the data processing 

system further comprising: 

means for accepting selection of one of the case identifications; and 
means, responsive to accepting selection of the case identification, for 

retrieving a medical record corresponding to the selected case identification for the 

selected patient identification for display at the client device. 

45 .A data processing system according to Claim 44 wherein the medical 
record comprises an anesthesia record. 

46. A data processing system according to Claim 45 wherein the anesthesia 
record comprises a date of a surgical operation, events occurring during the surgical 
operation, a graphical display of vital signs recorded during the surgical operation, 
and drugs administered during the surgical operation. 

47 . A data processing system according to Claim 43 wherein the means for 
retrieving scheduling information for scheduled operations meeting a predefined 
criteria comprises means for retrieving scheduling information for operations 
scheduled within a predetermined time period for an area of a hospital. 

48. A data processing system according to Claim 43 wherein the means for 
retrieving scheduling information for scheduled operations meeting a predefined 
criteria comprises means for retrieving scheduling information for operations 
scheduled with a designated physician within a predetermined time period. 

49. A data processing system according to Claim 43 wherein the scheduling 
information and the table for each of the scheduled operations further includes at least 
one selected from the group consisting of an operating room identification, a 
scheduled start time, an assigned physician, and a patient age. 

50. A data processing system according to Claim 43 wherein the patient 
identification for each scheduled operation includes at least one selected from the 
group consisting of a patient name and a patient identification number. 
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51. A data processing system according to Claim 43 further comprising: 
means for retrieving an alert from a pre-operative screening corresponding to a 

patient identification included in the table of scheduled operations meeting the 
predefined criteria, wherein providing the table of scheduled operations meeting the 
predefined criteria includes providing an indication of the alert. 

52. A data processing system that displays anesthesia records comprising: 
means for accepting entry of information identifying a surgical operation 

wherein the information is entered via a client device in communication with the data 
processing system; 

means for retrieving anesthesia data corresponding to the identified surgical 
operation; 

means for building an anesthesia record using the retrieved anesthesia data; 

and 

means for providing secure communication of the anesthesia record to the 
client device for display of the anesthesia record at the client device. 

53. A data processing system according to Claim 52 wherein the anesthesia 
record comprises a date of a surgical operation, events occurring during the surgical 
operation, a graphical display of vital signs recorded during the surgical operation, 
and drugs administered during the surgical operation. 

54. A data processing system according to Claim 53 wherein the means for 
providing secure communication of the anesthesia record comprises means for 
providing secure communication of the anesthesia record corresponding to the 
identified surgical operation while the identified surgical operation is in progress. 

5 5. A data processing system according to Claim 54 further comprising: 
means for retrieving updated information after providing secure 

communication of the anesthesia record to the client device, the updated information 
including at least one selected from the group consisting of a new event occurring 
during the surgical operation, a new measurement of vital signs, and a new drug 
administered; and 
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means for providing secure communication of the updated information to the 
client device for display of an update of the anesthesia record at the client device 
while the identified surgical operation is in progress after retrieving the updated 
information. 

56. A data processing system according to Claim 52 wherein the anesthesia 
record comprises a graphical representation of events occurring during the identified 
surgical operation for display at the client device, the graphical representation 
including a time line divided into predetermined units of time with a plurality of 
events occurring during a period of time represented by a single unit on the time line 
being represented by respective discreet and distinguishable event icons. 

57. A data processing system according to Claim 56 further comprising: 
means for accepting selection of one of the discreet and distinguishable event 

icons; and 

means, responsive to accepting selection of one of the discreet and 
distinguishable event icons, for providing text identifying the event corresponding to 
the selected discreet and distinguishable event icon for display at the client device. 

58. A data processing system according to Claim 52 wherein accepting entry of 
information identifying a surgical operation comprises accepting entry of a selection 
of a patient identification. 

59. A data processing system according to Claim 58 wherein the patient 
identification includes at least one selected from the group consisting of a patient 
name, and a patient identification number. 

60. A data processing system according to Claim 52 wherein the means for 
accepting entry of information identifying a surgical operation comprises means for 
accepting entry of a selection of a case identification. 

61 .A computer program product that displays operation scheduling 
information for a hospital surgical area including a plurality of operating rooms, the 
computer program product comprising a computer useable storage medium having 
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computer readable program code embodied in the medium, the computer readable 
program code comprising: 

computer readable program code that retrieves scheduling information for 
scheduled operations in the plurality of operating rooms of the hospital area over a 
predetermined time period wherein the scheduling information for the scheduled 
operations includes a patient identification and a procedure identification; 

computer readable program code that retrieves current status information for at 
least one of the scheduled operations while in progress wherein the current status 
information is selected from a plurality of milestones of a surgical operation while in 
progress; and 

computer readable program code that provides a table of scheduled operations 
over the predetermined time period for display at a client device wherein for a 
scheduled operation, the table includes the respective patient identification and 
procedure identification wherein the table further includes the current status 
information. 

62. A computer program product according to Claim 61 wherein the plurality 
of operating rooms is equipped with a respective electronic data entry system wherein 
the computer readable program code that retrieves current status information retrieves 
current status information entered into the respective electronic data entry system. 

63 .A computer program product according to Claim 62 wherein at least one of 
the data entry systems comprises an anesthesia information system workstation. 

64. A computer program product according to Claim 61 wherein the hospital 
area further includes a plurality of preoperative preparation areas and postoperative 
recovery areas and wherein the operating rooms, preoperative preparation areas, and 
postoperative recovery areas are equipped with respective electronic data entry 
systems, and wherein the computer readable program code that retrieves current status 
information retrieves current status information entered into the respective electronic 
data entry system. 
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65. A computer program product according to Claim 61 wherein the computer 
readable program code that retrieves current status information retrieves current status 
information at regular intervals, the computer program product further comprising: 

computer readable program code that refreshes the table on receipt of new 
current status information and that provides the refreshed table for display at the client 
device. 

66. A computer program product according to Claim 61 wherein the 
scheduling information and the table for the scheduled operations further includes at 
least one selected from the group consisting of an operating room identification, a 
scheduled start time, an assigned physician, and a patient age. 

67. A computer program product according to Claim 61 wherein the patient 
identification for the scheduled operations includes at least one selected from the 
group consisting of a patient name and a patient identification number. 

68. A computer program product according to Claim 61 the current status 
information includes a surgical event and a time of the surgical event. 

69. A computer program product according to Claim 61 further comprising: 
computer readable program code that accepts selection of a patient 

identification from the table of scheduled operations; 

computer readable program code that retrieves at least one case identification 
corresponding to the patient identification responsive to accepting selection of the 
patient identification; and 

computer readable program code that provides the at least one case 
identification corresponding to the patient identification for display at the client 
device. 

70. A computer program product according to Claim 69 wherein the at least 
one case identification comprises a plurality of case identifications, the computer 
program product further comprising: 

computer readable program code that accepts selection of one of the case 
identifications; 

50 



WO 03/025703 



PCT/US02/29354 



computer readable program code that retrieves a medical record corcesponding 
to the selected case identification for the selected patient identification responsive to 
accepting selection of the case identification; and 

computer readable program code that provides the medical record for display 
at the client device. 

71 .A computer program product according to Claim 70 wherein the medical 
record comprises an anesthesia record. 

72. A computer program product according to Claim 71 wherein the anesthesia 
record comprises a date of a surgical operation, events occurring during the surgical 
operation, a graphical display of vital signs recorded during the surgical operation, 
and drugs administered during the surgical operation. 

73 .A computer program product that retrieves medical information, the 
computer program product comprising a computer usable storage medium having 
computer readable program code embodied in the medium, the computer readable 
program code comprising: 

computer readable program code that retrieves scheduling information for 
scheduled operations meeting a predefined criteria wherein the scheduling 
information for the scheduled operations includes a patient identification and a 
procedure identification; 

computer readable program code that provides a table of scheduled operations 
meeting the predefined criteria for display at a client device wherein for each 
scheduled operation, the table includes the respective patient identification and 
procedure identification; 

computer readable program code that accepts selection of one of the patient 
identifications from the table of scheduled operations meeting the predefined criteria; 

computer readable program code that retrieves at least one case identification 
corresponding to the patient identification responsive to accepting selection of the 
patient identification for display at the client device. 
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74. A computer program product according to Claim 73 wherein the at least 
one case identification comprises a plurality of case identifications, the computer 
program product further comprising: 

computer readable program code that accepts selection of one of the case 
identifications; and 

computer readable program code that retrieves a medical record corresponding 
to the selected case identification for the selected patient identification responsive to 
accepting selection of the case identification for display at the client device. 

75. A computer program product according to Claim 74 wherein the medical 
record comprises an anesthesia record. 

76. A computer program product according to Claim 75 wherein the anesthesia 
record comprises a date of a surgical operation, events occurring during the surgical 
operation, a graphical display of vital signs recorded during the surgical operation, 
and drugs administered during the surgical operation. 

77. A computer program product according to Claim 73 wherein the computer 
readable program code that retrieves scheduling information for scheduled operations 
meeting a predefined criteria retrieves scheduling information for operations 
scheduled within a predetermined time period for an area of a hospital. 

78. A computer program product according to Claim 73 wherein the computer 
readable program code that retrieves scheduling information for scheduled operations 
meeting a predefined criteria retrieves scheduling information for operations 
scheduled with a designated physician within a predetermined time period. 

79. A computer program product according to Claim 73 wherein the 
scheduling information and the table for each of the scheduled operations further 
includes at least one selected from the group consisting of an operating room 
identification, a scheduled start time, an assigned physician, and a patient age. 
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80. A computer program product according to Claim 73 wherein the patient 
identification for each scheduled operation includes at least one selected from the 
group consisting of a patient name and a patient identification number. 

81. A computer program product according to Claim 73 further comprising: 
computer readable program code that retrieves an alert from a pre-operative 

screening corresponding to a patient identification included in the table of scheduled 
operations meeting the predefined criteria, wherein displaying the table of scheduled 
operations meeting the predefined criteria includes displaying an indication of the 
alert. 

82. A computer program product that displays anesthesia records, the computer 
program product comprising a computer usable storage medium having 
computer readable program code embodied in the medium, the computer 
readable program code comprising: 

computer readable program code that accepts entry of information identifying 
a surgical operation wherein the information is entered via a client device in 
communication with the data processing system; 

computer readable program code that retrieves anesthesia data corresponding 
to the identified surgical operation; 

computer readable program code that builds an anesthesia record using the 
retrieved anesthesia data; and 

computer readable program code that provides secure communication of the 
anesthesia record to the client device for display of the anesthesia record at the client 
device. 

83. A computer program product according to Claim 82 wherein the anesthesia 
record comprises a date of a surgical operation, events occurring during the surgical 
operation, a graphical display of vital signs recorded during the surgical operation, 
and drugs administered during the surgical operation. 

84. A computer program product according to Claim 83 wherein the computer 
readable program code that provides secure communication of the anesthesia record 
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provides secure communication of the anesthesia record corresponding to the 
identified surgical operation while the identified surgical operation is in progress. 



8 5. A computer program product according to Claim 84 further comprising: 
computer readable program code that, after providing secure communication 

of the anesthesia record to the client device, retrieves updated information including 
at least one selected from the group consisting of a new event occurring during the 
surgical operation, a new measurement of vital signs, and a new drug administered; 
and 

computer readable program code that, after retrieving the updated information, 
provides secure communication of the updated information to the client device for 
display of an update of the anesthesia record at the client device while the identified 
surgical operation is in progress. 

86. A computer program product according to Claim 82 wherein the anesthesia 
record comprises a graphical representation of events occurring during the identified 
surgical operation for display at the client device, the graphical representation 
including a time line divided into predetermined units of time with a plurality of 
events occurring during a period of time represented by a single unit on the time line 
being represented by respective discreet and distinguishable event icons. 

87. A computer program product according to Claim 86 further comprising: 
computer readable program code that accepts selection of one of the discreet 

and distinguishable event icons; and 

computer readable program code that, responsive to accepting selection of one 
of the discreet and distinguishable event icons, provides text identifying the event 
corresponding to the selected discreet and distinguishable event icon for display at the 
client device. 

88. A computer program product according to Claim 82 wherein the computer 
readable program code that accepts entry of information identifying a surgical 
operation accepts entry of a selection of a patient identification. 
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89. A computer program product according to Claim 88 wherein the patient 
identification includes atleast one selected from the group consisting of a patient 
name, and a patient identification number. 

90. A computer program product according to Claim 82 wherein the computer 
readable program code that accepts entry of information identifying a surgical 
operation accepts entry of a selection of a case identification. 
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